コラムColumn

■問題検出シナリオ
　前回、検出すべき重大な問題を設定した上でレビューすることでレビューの効果を高めることができることを紹介しました。この検出すべき重大な問題とその見つけかたをまとめて問題検出シナリオとして、準備することをお勧めしています。「性能に注意して見る」「信頼性を確認する」といった抽象的な指示では、レビューアーによって解釈がばらつき、検出できないことがあります。そこで、具体的な確認手順を問いのかたちでチェックのしかたとして決めておきます(図)。

図 問題検出シナリオ

　たとえば、月曜日朝に多くの社員が利用する社内システムがあるとします。そして、月曜日朝に業務システムの応答時間が長くなって社員の業務を滞らせたくないというときに検出すべき重大な問題は「利用が集中すると応答が遅くなる」です。そのチェックのしかたは「月曜日朝をはじめ利用が集中するときを想定し、開始から終了までの処理順序に従って構成要素（機能）を順に追って利用者にとっての応答時間が極端に長くならないか確かめる」のように、レビューアーが手を動かせるレベルまで具体化します。
　問題検出シナリオは一度作って終わりではなく、見逃した重大な問題の振り返りを通じて改訂し、資産として蓄積していきます。問題検出シナリオはチェックリストと同じようなものですが、チェックリストには問題の見つけかたが書いていないものもあります。また、過去に見逃されていた問題の未然防止を目的としてチェックリストに追加していると必ずしも重大な問題に限定したものになっていません。このようなチェックリストと区別するために「問題検出シナリオ」という名称をつけています。すでにチェックリストを活用されている場合には、まず、重大な問題を見つけるためのチェックリストに限定し、問題の見つけかたが書かれていなければ追加します。そうすると問題検出シナリオとして活用できます。

■問題検出シナリオの作りかた
　問題検出シナリオには2種類の作りかたがあります。一つは、過去にレビューで検出した重大な問題やレビューで見逃していた重大な問題をもとに作ります。たとえば、過去にデータベースの性能が十分でなく、システムテストで性能向上のためにテーブルやソースコードの大幅な変更が必要になったことがあるとします。今回、データベース問い合わせの追加、変更がありる場合には、テーブルへのクエリやその頻度を想定し、実際の運用でも期待する応答時間になるかをレビューで確かめます。データベースへの問い合わせの追加や変更をしないときには、この問題は今回のレビューではチェックする必要がありません。このように、過去の重大な問題であっても、今回実施しようとしているレビューでは同様の問題が起きえないときには対象外とします。
　もう一つの作りかたは、ソフトウェアやシステムに求められる大事なことが実現できているかどうかを想定し、それを阻害する原因を検出すべき問題とする方法です。たとえば、社内用の申請・承認システムで申請の内容、日時、申請者や承認者といった記録がなくなったり申請・承認結果を後から参照できなくなったりすると申請・承認システムとしての役目を果たせなくなります。こうしたソフトウェアやシステムにもっとも大事なことが期待通り実現できるかどうかを確かめます。検出すべき重大な問題として、申請内容や承認が記録できなくなること、及び、参照できなくなることとします。そのチェックのしかたは、申請や承認の記録方法や途中でシステムトラブルがあったときでも記録が残るような仕組みがあるか、申請者、承認者が退職しても記録が取り出せるか、権限がない利用者が変更、削除できてしまわないか、申請や承認を後から参照しようとしたときに一定期間が過ぎると検索結果として現われなくなってしまわないかといったことが上げられます。これらが起こらないかを確かめる方法をチェックのしかたとして問題検出シナリオとします。
　レビューアーの人数や規模、問題検出シナリオのチェックのしかたの複雑さにもよりますが、こうした問題検出シナリオを多くても一人あたり4件程度に抑えます。レビューアーが集中して検出できるようにするためです。レビューアーの得意、不得意に応じて問題検出シナリオを割当てます。原則として同じ問題検出シナリオを複数のレビューアーには割当てません。新人のフォロー、念入りに確認したい、重点化したいというときに限って、同一の問題検出シナリオを複数のレビューアーに割当てます。
　また、十分にスキルがあるレビューアー(有識者)には問題検出シナリオを割当てず、他のレビューアーにどういう問題検出シナリオが割当てられているかを知らせておき、それらに該当しない点をチェックしてもらうように依頼します。
　拙著第３版、改訂版では、これらの2種類の問題検出シナリオの作りかたをそれぞれ2例で説明しています。お近くにあれば、52～80ページ「なぜ重大な問題を見逃すのか？間違いだらけの設計レビュー第3版」または「なぜ重大な問題を見逃すのか？間違いだらけの設計レビュー改訂版」を参照ください。

■生成AIを使ったレビュー
　生成AIの性能が急速に向上しており、ソフトウェア開発に使えないか試行されている方も多いと思います。ソフトウェアドキュメントのレビューでもドキュメントを生成AIに与えて、問題を指摘させたくなります。まだまだ明らかになっていないことが多く、これからという段階ですので、ここでは比較的初歩的ではあるけれどよく起こる課題を2つ紹介します。
　一つ目は、長いドキュメントを対象にすると適切な回答(レビュー指摘)が得られにくくなることです (Lost in the middle問題)。期待する指摘を得られないときは、まずはドキュメントを分割して与えて指摘できる問題が増えるかどうかを確かめてみてください。
　短くすると指摘件数が増えたり指摘の内容が期待するようなものになったりしていれば、次に確かめていただきたいのはドキュメントに書かれていない内容を指摘させようとしていて、しかもその情報が一般的でない(生成AIの学習データに含まれていない)ものでないかです。極端な例を挙げると、生成AIに「エラーコードが定義通りかを確かめてください」と指示しているけれど、生成AIには与えていない付録の部分にエラーコードの定義が書いてあり、公開されている標準等でもそのエラーコードは定義されていない場合です。
　生成AIにレビューさせるときの適切な方法は、まだまだわかっていないことが多いので試行錯誤が続くと思いますが、生成AIモデルの高性能化に伴ってできることは増えていくと思います。

※このコラムは今回が最終回です。本コラムへのご意見・ご感想はこちらへお願いいたします。